package ecop017;

/*
 * 3-30-14.  New version of ecop017 rebuilt by Jason 3-21-14.
 * Questions:
 *   1.  Why isn't AlphaComposite needed anymore?  (Study the new paint routines)
 *   2.  I need to understand the "invokeLater" statement in main:  it has
 * to do with updating the GUI (which we don't have yet, though we do have
 * update in the gameLoop method).
 *   3,  Why can't Ecopia extend JPanel?
 *   4.  What does "frame.pack" in the run method do?
 *   5.  Often, but not always, running the program results in a 
 * "ConcurrentModificationException error, though the program continues to run.
 * It is happening in the "for(Camp c : camps) {"  line in Sector.Paint.  I
 * tried making Sector.Paint synchronized, but that did not help.

 */


/*

31 March 2014
Revisions by JKL

A)  Refactored Ecopia to its own file for organization.  Added to
    Ecopia.paintComponent.

B)  Created EcoZone class.  Added initializers in Ecopia.  Added to
    Ecopia.paintComponent.  Removed previous paint code.

C)  Removed Ecopia.syears -- int automatically cast to string during
    concatenation

D)  The -- and ++ operators decrement and increment by 1, respectively
    (x=x+1) == (x+=1) == (x++).  These operators can also precede your
    variable as in (--x) and (++x).  The difference is that the increment or
    decrement will take place either before or after evaluation.  In a statement
    by itself it doesn't make any difference, but consider this.

    x = 0;
    if(x++ > 0) print "greater" else print "not greater"
    if(x > 0) print "greater" else print "not greater"

    The output is "not greater", "greater"

    However,

    x = 0;
    if(++x > 0) print "greater" else print "not greater"
    if(x > 0) print "greater" else print "not greater"

    The output is "greater", "greater"

E)  Smaller sectors fill faster than larger sectors.  Under the current scheme,
    I think each sector has an equal chance of getting a new settlement during
    each iteration.  Is that not ideal?  Under the old scheme, folks just
    settled wherever they wanted, oblivious to sector boundaries.  Sectors
    could be given a bias based on size, terrain, etc if desired.

F)  Uncommented and consolidated sector calculations into Sector.update.  I
    think what you had there should work fine, but we'll probably need some
    conditionals somewhere (I think in Sector.update since most of the
    conditionals are based on values contained by the sector).

G)  NullPointerException, as you probably know, typically means your code is
    referring to a variable that hasn't been initialized.  Most commonly a
    member of an Array or Collection.  Sometimes it's hard to track down but
    usually the line number will tell you which variable needs checking, and
    from there you can work backward to find how it's slipping through
    uninitialized.

H)  If I understand correctly, a "Decider" will be able to influence properties
    of a Sector, and maybe other things as well.  I think this still leaves
    those properties housed in the Sector, with methods called by a Decider.  My
    thinking is that it is the Sector that goes to war, for example, not the
    Decider.

I)  Classes are all currently drawing themselves.  A sector is "invisible" but
    contains things that are not -- Camp, ritualCenter.  Look at the paint()
    method there.  I didn't change it much.

J)  Player interaction with the map.  We can make any object clickable.  That
    could come later or we could start implementing it any time.

K)  The visual representation of an attack (or of anything else) is relatively
    straightforward to change given the code is nicely organized.  This is a
    good reason to leave things expandable (for example, we use "Shape" a lot
    even though in the case of Sectors and EcoZones everything is rectangular).
    If we decide to make hexagonal Sectors for whatever reason it shouldn't
    be too much work.  So, a red arrow makes good sense.  It looks like an
    attack to me.

L)  I can't think of any special attribute of Java relating to a grid.
    It sounds like something we could implement as part of the UI.

*/

import javax.swing.JFrame;

/**
 * @author awj, revised by jkl 3-21-14.
 */

public class Ecop017 {
  public static void main(String[] args) {
    javax.swing.SwingUtilities.invokeLater(new Runnable() {
      @Override
      public void run() {
        JFrame frame = new JFrame( "ECOPIA" );
        frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE);
        frame.setContentPane(new Ecopia());
        frame.pack();
        frame.setVisible(true);
      }
    });
  }
}

    
     
